Understanding Media Services
The technical
requirements for providing access to audio and video media can differ
significantly from requirements for other types of content. The Web
Server (IIS) server role can provide access to many types of files to
your users. For example, you can enable users to download Windows Media
Audio (.wma) and Windows Media Video (.wmv) files by providing them with
the appropriate URL and access permissions. The drawback of this
approach, however, is that users typically will need to download an
entire file before they can start using it. The need to wait for a
complete file download offers a poor end-user experience. Many users
will choose not to wait for the media due to this inconvenience.
Whenever users request large video and audio files, Web servers attempt
to send the information as quickly as possible. This reduces the
performance of the server for other users of the server and limits
overall scalability. The download process can also waste significant
resources if users decide they do not want the entire file.
All
these issues are reasons for using a specialized service for serving
media content. The primary purpose of the Streaming Media Services
server role in Windows Server 2008 is to provide access to both live and
on-demand audio and video content over standard communications
protocols such as those used on the Internet. Media can be made
available in an intranet scenario or to users over a publicly accessible
Web site. In many cases, a Web application will include links that help
users easily locate and launch the content they need. Usually, the
content can begin playing within seconds, and the media server can
throttle network bandwidth automatically based on the client’s
connection speed and the desired quality. You can also use DRM to
protect the content provided to users.
Delivering Live vs. Prerecorded Content
Users can use Windows
Media Services to access two main types of content. Live broadcasts
typically are used for events such as sportscasts, music concerts, and
company meetings. The original source for live broadcasts is usually a
server or camera that supports the Windows Media Encoder standard. This
type of content starts at a specific time, and all users will receive
the same audio or video content. Because the data is being sent as it is
generated, users are unable to pause, fast-forward, or replay the
content during the live event. Live broadcasts can, however, be archived
so that users can access them on demand at a later time.
Prerecorded content
is available to users on demand. Examples include access to a library of
training videos, music videos, television shows, or other content that
is available upon request. When users request content, Streaming Media
Services starts sending it immediately. As soon as the client computer’s
media player has buffered enough of the data stream, the playback can
begin. The buffering process often takes only a few seconds, so playback
usually begins very quickly. Content developers can also create Web
pages that include an embedded media player to provide easy access to
content and associated information. Additionally, users can stop, pause,
fast-forward, or rewind the playback when accessing on-demand content.
Understanding Unicast vs. Multicast Streaming
An important goal
for providing access to streamed audio and video content is to reduce
network bandwidth requirements. Both clients and servers often have
limitations that can reduce scalability and can reduce the number of
users who can access media. Windows Media Services provides two methods
of sending data to clients.
Unicast streaming is based on
a direct one-to-one connection between client computers and the media
server. This is the most appropriate approach for scenarios in which
users should be given the ability to start playing any content on
demand. Because the content is sent individually to each client, users
can pause, replay, or fast-forward content in their media player. The
primary drawback of the unicast approach is that it can consume a
significant amount of network bandwidth. With
multicast streaming, many clients can subscribe simultaneously to the
same stream from a server. Server bandwidth requirements are minimized
because the information is sent only once. As long as the network
infrastructure supports multicast routing and distribution, clients can
then receive the content without requiring a direct connection to the
server. Multicast streaming is most appropriate for delivering live,
broadcast-based media because users will be unable to control the
playback of the stream. Multicast streaming is also well suited for
internal corporate networks where administrators can ensure that the
infrastructure supports it.
Comparing Data Transfer Protocols
Content providers must
design their streaming media services to ensure accessibility and
performance. Windows Media Services supports different protocols based
on client and network capabilities. The Real-Time Streaming Protocol (RTSP)
provides an efficient method to send audio and video content to
computers that are running Windows Media Player 9 or later. RTSP can use
the User Datagram Protocol (UDP, referred to as RTSPU), if it is
supported by the client and network. If UDP is not supported, RTSP can
use TCP (RTSPT). The default TCP port for connections is 554, but you
can change this setting to support specific firewall requirements.
Windows Media Services
can also stream information, using the HTTP protocol to support clients
or networks that do not support RTSP. By default, data is sent on HTTP
port 80, but the port can be changed to avoid conflicts with the Web
Server (IIS) server role. To simplify the connection process, Windows
Media Services provides a feature called automatic protocol rollover.
This feature can determine the most appropriate connection type
automatically for a particular media player client and send data using
that method.
